Ebuild Revisions

Ebuild 可能具有与其有关系的 Gentoo 修订号。其为 -rX 后缀，其中 X 是整数

---

见文件命名规则。该组件必须用于 Gentoo 的改变，而不是上游的发布。如果 ebuild 没有显式的修订号，则它具有隐式的 -r0 修订号。

Ebuild 修订版通常用于两个目的：

1. 在做潜在的重大改变时，保留旧版本的 ebuild。
2. 当执行有意义的改变时传播软件包的重建，否则已经安装当前版本的用户不会注意到改变。

开发者鼓励使用常识来决定是否引入新的=-rX=修订版时。以下经验法则可以用作指导原则：

1. 如果更改可能导致软件包损坏，以至于要求用户还原到之前的版本（对于标记为稳定的软件包，每个非重要的修改都被归为此类），那么应该引入新的修订版并保留旧的版本。如果软件包有 stable 关键字，新的修订版应该降为 ~arch （见Keywording on Upgrades。对于任何修订版的 bump，新的 ebuild 应该基于之前的修订版，以确保修复不会意外丢失。
2. 如果更改对已安装了软件包的用户产生了很大的用户（修复运行时问题，改变安装文件等）并且它不会通过其他方式传播，那么 ebuild 应该重命名为新的修订版。如果软件包有 stable 关键字，那么它们应该不删除直接移动到新的修订版。提交 ebuild 时，应该使用=repoman commit –straight-to-stable=选项。
3. 否则，更改可以在 ebuild 的当前修订版完成。

需要新修订版的更改示例包括：

• 添加 patch 修复运行时问题
• 安装可能对用户有用的附加文件
• 向现有的 blocks 之一添加缺失的运行时依赖
• 添加缺失的构建时依赖，缺少该依赖会构建成功，但不正确（例如缺少某些功能）
• 限制运行时依赖版本，除非 := subslot 运算符触发重建

无需修订版即可进行更改的示例如下：

• 添加 patch 以解决导致用户无法构建软件的构建时问题。（因为它不影响已构建的用户）
• 添加不重要的文档修复
• 安装对比需要重新构建软件包（特别是如果预计很快有新的 bump），其价值相对较小（次要文档，编辑器语法文件，bash 补全）的附加文件。
• 添加缺失并导致构建失败的构建时依赖。
• 添加新的 USE flag 或删除已存在的（因为 USE flags 的变化可以通过触发 --changed-use 重新构建）
• 不重要的风格/ebuild 代码更改（只有新的代码等同于旧的代码）
• 导致软件包移动的依赖变化（slot move）